1. Field of the Invention
This invention is related in general to the field of interfacing with programmable logic devices (xe2x80x9cPLDsxe2x80x9d). In particular, the invention consists of a novel communication and control mechanism for querying the status of and controlling the behavior of field programmable gate array (xe2x80x9cFPGAxe2x80x9d) based systems.
Highly demanding computer processing tasks have generally been performed by software applications on general-purpose computers. Often these general-purpose computers are not adequate for the processing requirements of the applications and designers have been forced to employ solutions involving special-purpose hardware. Special-purpose hardware often requires detailed programming and extended effort to take advantage of the unique processing elements they possess. This extra programming effort introduces significant development costs for special purpose processing.
Software applications written in various programming languages such as xe2x80x9cCxe2x80x9d, MATLAB, Python, Midas 2K, and the like can control PLDs. The software applications are run on general purpose processors, special purpose processors, or embedded processors. Some PLDs have inherent microprocessors which run software applications. For example, the VIRTEX II PRO CHIP(copyright) FPGA has an embedded POWER PC(copyright) processor for running software applications. PLDs are comprised of functional units, each providing a computational function. Some functional units employ large proprietary algorithms called xe2x80x9ccoresxe2x80x9d. A core can be treated as a xe2x80x9cblack boxxe2x80x9d during a design process, wherein knowledge of a functional unit""s behavior is known, but knowledge of the composition of the functional unit is not required. Typically, knowledge of a core""s communication path, inputs and outputs, attributes and behavior are necessary to utilize the core.
One method of communicating with functional units and their cores is to use an Application Program Interface (xe2x80x9cAPIxe2x80x9d). APIs are software interface constructs that provide specifications of functions provided by hardware devices which can be requested by software applications. However, traditional APIs require software applications to have specific knowledge of detailed functional unit information, such as register addressing, control and status bit information, control access sequences, and functional unit timing diagrams to properly communicate with and control these hardware devices. For example, a software application that attempts to set a frequency attribute of a digital tuner core inside an FPGA would typically need a register address inside the functional unit associated with the frequency attribute. Additionally, the application might also need to access the functional unit via some control sequence that accesses specific bits in a specific control register. A programmer would explicitly indicate the register address in a software application that wishes to set the frequency attribute parameter and then perform the appropriate control sequence to transfer data to this register address. If the register address changes due to a modification of a functional unit or design implementation with a different FPGA design, or the control sequence is altered for similar reasons, the software application would not function properly, as the coded register address no longer points to the frequency attribute register and the control sequence and control information may be different. A programmer would need to modify the programming code for the software application to match these changes in the hardware design.
If a software application requests a function via an API, the function will partition the request into discrete steps that can be performed by the hardware. Only those hardware functions that are described by the API are available to the software application. If a hardware device has additional features or attributes not recognized by the API, they are typically not available for use by the software application.
There has been an attempt to establish an industry standard input/output (xe2x80x9cI/Oxe2x80x9d) interface for software applications such that API calls may be uniform. An attempt has also been made to utilize these industry standard I/O interfaces by developing industry standard hardware interfaces. The result is a uniform set of API software calls producing uniform stimulation of hardware devices. This is useful for establishing a standard method of transferring data between software applications and functional units (in the cases above, the drivers will still be different, but encapsulated by these API calls). However, this standard does not provide a method of controlling the attributes of functional units. A change of hardware design would still require a corresponding change in application software.
One patent which discloses attempts to improve on methods of controlling FPGAs is Davis et al. U.S. Pat. No. 6,230,307, entitled SYSTEM AND METHOD FOR PROGRAMMING THE HARDWARE OF FIELD PROGRAMMABLE GATE ARRAYS (FPGAS) AND RELATED RECONFIGURATION RESOURCES AS IF THEY WERE SOFTWARE BY CREATING HARDWARE OBJECTS. Davis discloses a system that controls the behavior of FPGAs as if they are software by creating hardware objects that implement application level functions. Control and execution of hardware objects occurs via high level software constructs. However, a change in a function in an FPGA will necessitate that a new hardware object be created. Thus, every time a design adds or changes an FPGA core, a new hardware object must be written and the software applications must be re-compiled to integrate this new object. This eliminates the need to re-code software applications when designs change, but introduces a requirement of coding new hardware objects to reflect changes to functional units. This patent does not disclose run-time control of functional unit attributes nor does it provide a software object that represents the functional unit hierarchy with attribute control. Run-time reconfiguration is disclosed but not run-time control.
A second patent of interest is Athanas et al. U.S. Pat. No. 5,828,858, entitled WORM-HOLE RUN-TIME RECONFIGURABLE PROCESSOR FIELD PROGRAMMABLE GATE ARRAY (FPGA). Athanas discloses a methodology of using dynamically created operators and pathways to move data between functional units through configurable interconnections. This invention makes use of dynamically changeable variable length data ports. While Athanas discloses a novel approach to interconnecting functional units, it does not address a method of allowing software applications to query these functional units to ascertain their attributes. Nor does Athanas provide a method of controlling functional units without prior detailed knowledge of their attributes.
Another reference is Mohan et al. U.S. Pat. No. 6,216,258, entitled FPGA MODULES PARAMETERIZED BY EXPRESSIONS. Mohan discloses parameterizing functional modules of target specific FPGAs. This provides a standard method of representing FPGA attributes. While these parameters are visible to high level software applications, applications must still be hard-coded to access these parameters directly.
In the methods discussed, a system designer must have intimate knowledge of underlying hardware in order to effectively integrate the hardware into a given software environment. Therefore, it is desirable to have a method of allowing software applications to communicate with and control hardware functional units without specific and detailed knowledge of a device""s parameters and attributes.
It is also desirable to have a method of changing hardware designs without necessitating that software applications be rewritten or re-compiled to integrate these hardware changes.
It is likewise desirable to allow software applications and hardware devices to be designed independently of each other, yet operate in a cohesive manner when integrated.
Previously, software applications controlling FPGA functional units have been designed for specific purposes and for specific software environments. Because system requirements change rapidly and increase in complexity, it is necessary for design solutions to be rapidly portable to new hardware platforms and be integrated into a variety of software application environments. It is desirable that a software interface be developed that allows numerous software applications to communicate with and control numerous hardware devices; adding or changing software applications can be done without affecting communication and control of existing hardware designs.
It is likewise desirable to have a hardware interface wherein numerous hardware devices can be queried and controlled by numerous software applications, and adding or changing hardware devices can be done without affecting communication with software applications.
The present invention meets the aforementioned needs by providing a software interface layer by which software applications may communicate with and control functional units residing in FPGAs or other PLDs without requiring detailed knowledge of associated FPGA hardware. The approach taken by the method of communication and control which is the subject of the present invention is to provide an interface layer between functional units inherent in FPGA hardware (including hardware platforms and FPGAs) and software applications. Each hardware functional unit is represented by a unique but standard Dynamic Object. The purpose of the Dynamic Object is to allow functional units to advertise their functionality and attributes to software applications. Additionally, software applications may utilize this functionality and set functional unit attributes without functional unit specific information such as FPGA hardware, functional unit composition, or functional unit implementation.
The invention described herein is referred to as a Dynamic Object Model. A Dynamic Object Model includes a front end program component, a back end program component, and a dynamic API program component (xe2x80x9ccontract negotiatorxe2x80x9d) for providing communication between the front end program component and the back end program component.
A Dynamic front end program component is a software construct that includes libraries and supporting files for software environments. A front end may be written to accommodate, for example, xe2x80x9cCxe2x80x9d, Matlab, Midas2k, or Perl software environments. A unique front end is written for each software environment. Changes to the front-end are only required if the dynamic API specification changes. The front end does not require modification when hardware designs are modified, i.e., changing a hardware platform does not require that a Dynamic Object Model front end be re-written.
A contract negotiator program component is a software construct providing a standard for the front end and the back end. A dynamic list of acceptable system calls is established that can be requested by the front end and performed by the back end. The preferred embodiment of the invention implements a fixed API. It is possible, however, to include in the API the ability to dynamically create new calls that can be used by the front-end. For instance, if the back-end creates an object that has a new method, the front-end could generate a method in the Dynamic Object to match it. To dynamically add new methods, the front and back end implementations must have agreement on function prototypes.
A back end is a software construct wherein software drivers are written for specific hardware platforms or software emulators. A hardware platform is a vendor specific circuit board, such as a Starfire FPGA board, designed to accommodate and support FPGAs or other PLDs. The back end incorporates interface information specific to the hardware platform. Once a back end has been written for a specific hardware platform, implementation of a different type of FPGA, changes to a FPGA design, or changes in the implementation of functional units do not require modifying the Dynamic Object Model back end.
The Dynamic Object Model back end produces a dynamic object for each functional unit inside each FPGA or PLD. These dynamic objects encapsulate functional unit specific information such as functionality, timing requirements and functional unit attributes. Using the dynamic API, the back end communicates available functional units and their attributes to the Dynamic Object Model front end as dynamic objects comprised of functions and parameters. The front end makes these dynamic objects available to its software applications.
A popular method of coding software applications is object oriented programming (xe2x80x9cOOPxe2x80x9d). In the present invention, software applications operate on dynamic objects representing functional units as if they are standard algorithmic objects. Control of functional units is handled by the functional unit specific information encapsulated by the dynamic objects rather than directly by the software applications. Software applications do not require knowledge of a functional unit""s function and attributes to implement functions and manipulate the parameters of it representative dynamic object.
Therefore, it is a principal object of this invention to provide a method of allowing software applications to communicate with and control hardware functional units without specific and detailed knowledge of functional unit specific information and attributes.
It is another object of this invention to provide a method of changing hardware designs without requiring that software applications be rewritten or re-compiled to utilize the hardware design changes.
It is yet another object of this invention to allow software applications and hardware systems to be designed independently, yet function cohesively when integrated.
It is a further object of this invention to provide a software environment that allows numerous software applications to communicate with and control numerous functional units and that permits adding or changing software applications without affecting communication and control of existing hardware designs.
An additional object of this invention is to provide a hardware interface wherein numerous hardware devices can be queried and controlled by numerous software applications and wherein adding or changing hardware devices can occur without affecting communication with software applications.